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ABSTRACT 

A  major  challenge  facing  the  MLS  community  is  to  find 
ways  to  provide  the  information  and  connectivity  that 
DoD  users  demand  without  either  imposing 
unacceptable  security  risks  or  requiring  expensive 
hardware  and  software  that  fails  to  mesh  with 
commercial  off-the-shelf  (COTS)  applications.  This 
paper  proposes,  very  briefly,  an  architecture  that  meets 
these  goals  using  only  a  small  number  of  relatively 
simple,  low  cost,  high  assurance  components  in 
combination  with  a  preponderance  of  unmodified  COTS 
hardware,  operating  systems  and  applications. 

INTRODUCTION 

The  computing  landscape  has  changed  dramatically  over 
the  past  decade,  evolving  from  a  world  of  stand-alone 
computers  whose  users  occasionally  exchange  email  to  a 
globally  networked  computing  environment  in  which 
resources  anywhere  can  be  accessed  anytime  by  almost 
anyone.  Recognizing  this  shift,  the  Joint  Security 
Commission  (JSC)  [1]  challenged  the  MLS  community 
to  find  better  ways  to  protect  national  security  resources: 
"Our  paradigm  for  managing  security  must  also  shift 
from  developing  security  for  each  individual 
application,  system,  and  network  to  developing  security 
for  subscribers  within  the  worldwide  utility." 

As  new  computing  paradigms  appear,  such  as 
distributed  object-oriented  computing,  DoD 
organizations  must  be  able  to  share  information, 
integrate  new  technologies  into  their  information 
systems,  and,  at  the  same  time,  protect  their  information 
and  guarantee  their  operational  advantage.  Commercial 
and  government  enterprises  have  turned  to  client-server 
architectures  to  achieve  global  interoperability.  For 
many  critical  functions,  however,  DoD  continues  to  rely 
on  legacy  systems  (stovepipe,  single -purpose,  inflexible, 
isolated  systems)  whose  design  and  puipose  never 


addressed  the  need  for  global  interoperability  and 
information  sharing. 

We  propose  a  security  architecture  that  can  be  applied  to 
a  system  or  to  a  globally  distributed  confederation  of 
heterogeneous  components  to  enable  reliable,  secure 
information  sharing  among  organizations  operating 
over  a  wide  range  of  security  levels.  First,  we  mention 
some  techniques  for  inter-enclave  information  sharing 
that  require  only  a  few  relatively  simple  security-critical 
components,  yet  can  make  information  available 
securely  to  the  widest  community  of  MLS  users.  We 
propose  three  principles  for  future  MLS  architectures 
and  summarize  an  architecture  based  on  them  that 
responds  to  the  JSC’s  challenge.  We  then  provide 
details  on  the  client  side  and  the  server  side  of  our 
proposed  architecture  and  describe  the  other 
components  required  for  the  comprehensive 
architecture.  Finally,  we  assess  how  our  architecture 
supports  both  security  requirements  and  needs  for 
interoperability,  support  for  legacy  systems,  and 
incentives  to  increase  information  sharing. 

SIMPLE  TECHNIQUES 
FOR  INFORMATION  SHARING 

Some  techniques  that  facilitate  inter-enclave 
information  sharing  through  the  use  of  relatively  simple 
security  critical  components  are: 

•  Replication  of  information  from  low  to  high 
systems,  as  demonstrated  in  SINTRA  prototypes  [2] 
using  COTS  replication  servers  in  conjunction  with 
the  NRL  Pump  [3],  a  reliable,  one-way  flow  device. 

•  Higher  level  user  access  to  lower  level  resources  on 
demand,  without  the  use  of  special  purpose  trusted 
operating  systems,  as  demonstrated  by  the 
Australian  Starlight  Interactive  Link  [4]  facility  at 
JWID  '96. 
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•  Assurance  of  information  privacy,  integrity,  and 
authenticity  through  judicious  use  of  cryptographic 
techniques. 

High  assurance  downgrading  is  presently  needed  in 
some  situations,  often  because  low  sensitivity  data  have 
been  imported  into  a  high  enclave  and  need  to  be 
exported  to  a  lower  level.  Simple,  high  assurance 
components  to  achieve  this  function  have  yet  to  be 
demonstrated.  In  the  long  term,  it  will  be  preferable  to 
collect  and  store  such  data  at  its  correct  sensitivity  level. 

PRINCIPLES  AND  ARCHITECTURE 

Our  response  to  the  JSC’s  challenge  is  based  on  three 
principles: 

•  Security  engineering  in  the  large:  Security  must  be 
designed  into  the  global  infrastructure.  High 
assurance  components  are  needed  for  strong 
separation,  while  low  assurance  security 
mechanisms  can  be  used  for  weak  separation. 

•  Separation  of  concerns:  Security  concerns  should  be 
focused  on  separate  components,  permitting 
maximum  use  of  COTS  components  to  meet  other 
functional  requirements. 

•  Minimize  MLS  access  to  shared  resources:  Accesses 
to  a  single  shared  resource  from  processes  at 
different  security  levels  is  the  major  source  of 
residual  vulnerabilities  in  MLS  systems.  Physical 
separation  and  data  replication  can  provide  the  same 
function  but  with  much  stronger,  more  effective 
protection. 

On  this  basis,  we  propose  to  build  a  secure 
heterogeneous  distributed  system  from  multiple  single- 
level  COTS  products  and  appropriate  simple,  special- 
purpose  security  components. 

There  are  two  parts  to  our  solution:  client  and  server. 
The  distributed  SINTRA  DBMS  and  the  NRL  Pump  are 
primarily  server  side  solutions.  The  Australian  Starlight 
Interactive  Link  (IL)  technology  represents  a  promising 
client  side  solution,  although  general  high-assurance 
approaches  for  handling  downgrading  need  attention. 
This  approach  reduces  cost  by  encouraging  the  use  of 
COTS  products,  provides  a  path  for  legacy  systems  to 
migrate  to  new  technologies,  and  promotes  information 
sharing  while  maintaining  the  security  and  autonomy  of 
organizations. 


Figure  1.  Server  Side  Solution:  SINTRA  with  Pump 

A  SERVER-SIDE  SOLUTION 

The  server-side  solution  is  based  on  the  following 
observations: 

1.  MLS  security  can  be  achieved  by  separation  of 
computing  resources,  and 

2.  Replication  of  low  information  to  high  systems  and 
applications  makes  low  information  available  to 
high  users. 

When  the  information  is  propagated  from  lower  to 
higher  level  systems,  we  need  a  one-way 
communication  component  that  assures  that  this 
communication  not  only  preserves  the  secure 
information  flow  but  also  guarantees  reliability, 
fairness,  availability,  and  performance.  The  NRL  Pump 
is  a  device  that  balances  the  above  requirements.  The 
server-side  solution  is  shown  in  Figure  1 . 

A  CLIENT-SIDE  SOLUTION 

Our  client-side  solution  is  based  on  the  following 
observations: 

1.  Security  can  be  achieved  by  separation  of 
computing  resources,  and 

2.  When  lower  level  information  or  services  are 
needed  by  higher  level  users,  they  can  be  provided 
by  establishing  a  separate  connection  to  lower  level 
systems. 

The  Starlight  Interactive  Link  is  a  device  developed  by 
the  Australian  Defence  Science  and  Technology 
Organization  (DSTO)  that  enables  the  user  of  a  COTS  X 
Windows  workstation  in  a  secure  enclave  to  redirect  the 
output  of  his  keyboard  to  login  to  lower  level  servers  to 
browse,  send  messages  or  have  data  sent  to  the  higher 
enclave  for  future  analysis.  In  other  words,  a  high  level 
user  can  establish  simultaneous  connections  to  systems 
at  many  lower  security  levels  through  a  Starlight- 
enabled  workstation.  The  client-side  solution  is  shown 
in  Figure  2. 
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Figure  2.  Client  Side  Solution:  Starlight  Interactive  Link 

COMPREHENSIVE  SECURITY  ARCHITECTURE 

The  security  architecture  can  be  achieved  by  combining 
the  server-side  and  client-side  solutions,  and  adding  a 
few  other  components  [5].  The  other  components  are 
needed  to  assure  privacy,  authenticity,  and  integrity  of 
messages  in  the  network  and  to  permit  downgrading. 
The  architecture  for  two  security  levels  shown  in  Figure 
3  can  be  extended  easily  to  handle  three  or  more  levels. 

ASSESSMENT 

Our  architecture  meets  the  security  requirements  as 
follows: 

•  Information  flow  from  low  to  high  system.  If  lower 
level  information  needs  to  be  sent  to  higher  level 
systems:  (1)  the  information  is  encrypted  and 
authenticated  (if  necessary),  (2)  it  is  sent  to  the 
Pump  through  a  network,  (3)  it  is  delivered  to  the 
final  destination,  and  (4)  it  is  decrypted  and  verified 
(if  necessary).  Note  that  steps  (3)  and  (4)  can  be 
reversed  depending  on  system  requirements. 


:  Downgrader 


:  Cryptographic  component 


J  :  Starlight-enable  workstation 


Figure  3.  Comprehensive  Architecture 


•  Privacy,  integrity,  authenticity  of  information.  If 
information  travels  through  an  unprotected  portion 


of  a  network  and  the  information  needs  protection, 
then  cryptographic  components  can  be  used. 

•  Higher  level  users  may  need  to  access  lower  level 
resources.  If  higher  level  users  need  to  access  lower 
level  information  that  has  not  been  replicated  to  a 
higher  level  system,  then  the  high  user  can  login  to  a 
lower  level  system  via  Starlight  Interactive  Link. 
Again,  if  the  network  is  not  protected  and  the 
information  requires  protection,  then  cryptographic 
techniques  should  be  used. 

•  Availability  of  resources.  No  single  technique  can 
solve  this  problem,  although  the  fault-tolerant 
community  uses  replication  to  increase  availability. 
Our  proposed  architecture  uses  replication  as  a  way 
to  share  lower  level  information  with  higher  level 
processes/users.  We  believe  that  minimal,  but 
cleverly  engineered  use  of  replication  can  also  help 
achieve  the  goals  of  availability,  performance,  and 
sharing. 

•  Downgrading.  If  there  is  a  need  to  downgrade 
information,  then  a  downgrader  should  be  used  (see 
figure  8).  If  the  downgraded  information  is  still  at  a 
higher  security  level  than  the  security  level  of  the 
unprotected  portion  of  the  network,  then 
cryptographic  techniques  should  be  used. 

Additional  benefits  of  our  approach  include: 

•  Reduced  cost.  The  overall  cost  of  our  approach  will 
be  much  lower  than  that  of  the  naive  extensions  of 
the  traditional  MLS  approach  because  our  approach 
encourages  the  use  of  commercially  available 
products. 

•  Provision  of  a  migration  path  for  legacy  systems. 
Legacy  systems  can  participate  in  new  federations 
without  jeopardizing  security  because  these  systems 
are  isolated  by  security  critical  components. 

•  Provision  of  a  migration  path  to  new  technologies. 
When  new  products  or  technologies  are  available, 
an  organization  can  incorporate  these  in  the 
federation  without  affecting  other 
organization/systems.  This  is  true  because  systems 
from  different  organizations  are  strongly  separated 
by  security  critical  components. 

•  Promotion  of  sharing,  security,  and  autonomy. 
Since  the  security  of  our  proposed  approach  is 
flexible  and  easy  to  understand,  it  encourages 
organizations  to  participate  in  federations  while 
retaining  full  control  of  their  own  systems.  Each 
organization  can  decide  which  critical  components 
are  needed,  depending  on  their  own  security  and 
functionality  needs. 
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